home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 3294 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.0 KB
  1. Path: dakal.demon.co.uk!richardlh
  2. From: Richard Linsley Hood <richardlh@dakal.demon.co.uk>
  3. Newsgroups: comp.lang.c++,comp.lang.pascal.delphi.misc
  4. Subject: Re: C++ with Zapp vs. Delphi
  5. Date: Mon, 22 Jan 1996 19:48:21 +0000
  6. Organization: Dakal Systems Ltd
  7. Distribution: world
  8. Message-ID: <fukt+AAFo+AxEwc9@dakal.demon.co.uk>
  9. References: <4coar6$d4n@sun4.bham.ac.uk> <4coip7$69s@news1.usa.pipeline.com>
  10.  <DBk8wg2yqjbB083yn@iaccess.za> <4d7pmb$48c8@tigger.cc.uic.edu>
  11.  <4dk38h$gdr@merlin.delphi.com> <4dksp1$3d6c@tigger.cc.uic.edu>
  12.  <30fe666e.3349285@130.15.126.54> <4dmjt8$6sv@crc-news.doc.ca>
  13.  <30ff9519.1799465@130.15.126.54> <4doe07$4u8@crc-news.doc.ca>
  14.  <30ffe557.16481026@130.15.126.54> <GK+N9LA3rQAxEwdx@dakal.demon.co.uk>
  15.  <AUSTERN.96Jan22100904@isolde.mti.sgi.com>
  16. NNTP-Posting-Host: dakal.demon.co.uk
  17. X-NNTP-Posting-Host: dakal.demon.co.uk
  18. MIME-Version: 1.0
  19. X-Newsreader: Turnpike Version 1.10 <EdeHes6g1FnzvsX+Q8nYPyW0xw>
  20.  
  21. In article <AUSTERN.96Jan22100904@isolde.mti.sgi.com>, Matt Austern
  22. <austern@isolde.mti.sgi.com> writes
  23.  
  24. >In article <GK+N9LA3rQAxEwdx@dakal.demon.co.uk> Richard Linsley Hood 
  25. ><richardlh@dakal.demon.co.uk> writes:
  26. >
  27. >> The method and order by which comparisons are done is determined by the 
  28. >> list. This is quite reasonably part of its function. It 'knows' about 
  29. >> which two items should be compared to determine which is larger, 
  30. >> smaller, etc., thus it is part of its function.
  31. >> 
  32. >> The comparison of two objects should be done by themselves, 'are you 
  33. >> larger, smaller than this object' thus hiding from the list how this is 
  34. >> done. Only an object 'knows' how it compares to another object (of the 
  35. >> same type). This is quite reasonably a function of the object.
  36. >> 
  37. >> Where is the problem?
  38. >
  39. >The problem is that I might want to have one list of employees
  40. >arranged alphabetically by last name, one list arranged alphabetically
  41. >by first name, another arranged by numerical value of the employee ID,
  42. >and another arranged chronologically by date of hire.  
  43. >
  44. >For a nontrivial object (like an employee record), there are too many
  45. >reasonable choices for the comparison function.  An object shouldn't
  46. >necessarily impose one choice on all of its clients.
  47.  
  48. For a complex object, such as you describe, with a complex requirement 
  49. for ordering in separate lists as stated I would do the following.
  50.  
  51. Create a base class for 'anindex' containing a virtual item 'index' and 
  52. a pointer to 'employee' (a friend class to 'employee' if required, else 
  53. operating on public members of 'employee').
  54.  
  55. Derive from the 'anindex' base class the required sub-classes that 
  56. incorporate your designated sort requirements with actual 'index' 
  57. properties of the correct type.
  58.  
  59. Create one or more lists than contain the base class 'anindex'. Add 
  60. 'anindex' items to the lists as required.
  61.  
  62. Very simple class structure, with remarkably little effort, easily 
  63. extendible and completely sufficient to meet your requirements.
  64.  
  65. -- 
  66. Richard Linsley Hood | Poole, Dorset UK | email: richardlh@dakal.demon.co.uk
  67. "Programming is mirroring the world, inside a computer"   Larry O'Brien 1991
  68.